Database system and method with improved locks

ABSTRACT

A method for handling database locks includes detecting a new query from an administrator for a set of database records. Next, it is determined whether the administrator has any chance of being authorized to acquire a new lock. If so, an attempt is made to acquire the new lock and, on the failure to acquire, the administrator is informed that the lock has already been acquired by a prior administrator. Optionally, the new administrator is also provided with identifying information of the prior administrator and contact information for the prior administrator. The new administrator is therefore pre-screened to determine whether there is any chance to acquire a new lock to reduce the chance that an unauthorized new administrator could lock the set of database records. Also, should the new administrator be authorized but not able to access the set of database records due to a prior lock, the new administrator can be informed of the identity and contact information concerning the holder of the prior lock.

TECHNICAL FIELD

This invention relates generally to database management systems, andmore particularly to the handling of locks for database records.

BACKGROUND ART

Computerized databases are used to store large amounts of information.This information is often organized in a hierarchical fashion, e.g. intofields, records, sets, etc. Such a hierarchical organization tends to bevirtual, rather than physical, based upon the algorithms implemented bythe database management systems.

Databases can be of various types, including flat databases andrelational databases. Generally speaking, relational databases arepreferred when dealing with large numbers of records which need to beaccessed in a variety of ways. For example, many business organizationsuse a relational database to handle their human resource (“HR”)function.

Databases are usually administered by one or more databaseadministrators. In small organizations, such in a small business, theremay be only one administrator for the database. This has the advantageof simplicity, in that it reduces potential conflicts. However, in largecompanies it is impractical to have a single administrator to handle anentire database function, e.g. the HR database function and, therefore,conflicts between multiple administrators occur and must be handled.

One way to handle the potential conflict of having multipleadministrators trying to access and perhaps change the same data can behandled with the provision of database locks. That is, if a firstadministrator (referred to herein as a “prior administrator”) accesses aparticular set of records, a “lock” on those records can be implementedsuch that a second administrator (referred to herein as a “newadministrator”) is prevented from at least changing that those records.In many instances, the new administrator may be prevented from evenviewing the locked files.

This method of locking portions of a database has the advantage ofpreventing the inherent conflicts and potential instability of thedatabase when two or more administrators access the same data at thesame time. For example, if both administrators were attempting to updatethe same field within a record, the system could be destabilized anddata could be lost or corrupted.

A problem that happens from time to time in large organizations is thata prior administrator unnecessarily locks out a new administrator. Forexample, with systems in the prior art, when a prior administrator firstaccesses or “queries” the records, a lock is immediately put in place.However, it could be that the prior administrator does not even haveprivileges sufficient to allow access to those records. In consequence,neither the prior administrator nor the new administrator can accessthat information. In fact, until the prior administrator has releasedthe lock, no new administrator can be provided with access to thosefiles. This can be very troublesome in large organizations where theremay be hundreds of administrators located in multiple countries aroundthe world. That is, it maybe hard to identify the administrator who islocking up the records and, in fact, the records may become inaccessiblefor an extended period of time.

This problem has no easy solution, and has been long-felt in theindustry. The logical solution would be not provide a lock to anypotential administrator if they do not have the authority to view ormanipulate those records. However, to fully check all of the privilegesfor all applicable records might require thousands of database queries.Even with modern, high speed computers such searches would be too timeconsuming to be practical.

DISCLOSURE OF THE INVENTION

An aspect of the present invention includes a quick, preliminaryscreening method to prevent an administrator from creating a lockwithout proper authority. While this preliminary screening will not beentirely conclusive, it can eliminate a very high percentage ofinstances where its is clear that an administrator has no chance ofbeing authorized to access that set of records. In fact, in tests on asample system, the preliminary screening can identify about 95% of theinstances when an administrator has no chance of being authorized toaccess a set of records. The small percentage of time (5% in thisexample) when the administrator is not screened out by the preliminaryscreening and it turns out that the administrator was, indeed, notauthorized, the system is no worse off than it had been prior toimplementing the pre-screening methodologies of embodiments of thepresent invention.

Briefly, a method for handling database locks in accordance with anembodiment of the present invention includes detecting a new query froma new administrator for a set of database records capable with beingassociated with a new lock. When the new query is detected, it isdetermined with a preliminary screening whether the new administratorhas any chance of being authorized to acquire the new lock. If it isdetermined that the new administrator does have a chance of acquiring alock, the system attempts to acquire the new lock. If, however, the newadministrator fails to acquire the new lock, the new administrator isinformed to that fact. Optionally, the new administrator can be providedwith information identifying the prior administrator that holds a priorlock. Also optionally, the new administrator can be provided withcontact information for the prior administrator, such that the prioradministrator can be contacted to determined if the prior lock is stillrequired.

In another aspect of the present invention, a computer readable mediaincluding program code segments for handling database locks includes acode segment for detecting a new query from a new administrator, a codesegment determining whether the new administrator has any chance ofbeing authorized to acquire the lock, a code segment attempting toacquire the new lock if the new administrator has a chance of beingauthorized, and a code segment informing the new administrator of afailure to acquire the new lock. Optionally, the code segment informingthe new administrator can identify the prior administrator. Furtheroptionally, the code segments for informing the new administrator caninclude contact information for the prior administrator.

In another aspect of the present invention, a method for making apreliminary determination as to whether a database administrator hasauthorization to access a set of database records includes determiningwhether a database administrator has no chance of being so-authorized.In particular, a method in accordance with an embodiment of the presentinvention determines that a database administrator has no chance ofbeing authorized to access a designated set of database records if thedatabase administrator does not have one or more of (a) writeauthorization; (b) a lack of conflict of interest; (c) organizationalpermission; or (d) current authorization. The method of the disclosedembodiment also includes determining that a database administrator has achance of being authorized if the database administrator has one or moreof: (a) write authorization and maximum administrator authorization; and(b) write authorization, no conflict of interest, organizationalpermission, and current authorization.

Another aspect of the present invention includes a computer readablemedia including program code segments for implementing theaforementioned method for making a preliminary determination as towhether a database administrator has authorization to access a set ofdatabase records.

Yet another aspect of the present invention includes a database systemincluding locks including means for detecting a new query from a newadministrator for a set of database records presently associated withthe new lock, means for determining whether the new administrator hasany chance of being authorized to acquire the lock, means for attemptingto acquire the new lock if the new administrator has a chance of beingauthorized, and means for informing the new administrator of a failureto acquire the new lock if a prior lock has already been acquired due toa prior query by a prior administrator. Optionally, the database systemcan further include means for identifying prior administrators, andmeans for providing contact information for the prior administrator.

Another embodiment of a database system in accordance with the presentinvention includes a number of administrative terminals, and a databaseserver capable of being accessed by those administrative terminals. Thedatabase server includes at least in part, a database program capable ofmanaging a number of records. The database program preferably includesthe functionality of: (a) detecting a new query from a new administratorat a new administrator terminal for a set of database records that isassociated with the new lock; (b) determining whether the newadministrator has any chance of being authorized to acquire the newlock; (c) attempting to acquire the new lock if the new administratorhas a chance of being authorized; and (d) informing the newadministrator at the new administrator terminal of a failure to acquirethe new lock if a prior lock has already been acquired due to a priorquery by a prior administrator on a prior administrator station.Optionally, informing the new administrator includes identifying, on anew administrator station, the prior administrator. Also optionally,informing the new administrator includes, on the new administratorstation, providing contact information for the prior administrator.

An advantage of the various embodiments and aspects of the presentinvention is that there is a quick, efficient, preliminary screening ofadministrators to prevent them from acquiring locks when there is nochance that they will authorized for those files. By providing a quick,preliminary screening, the majority of instances when an administratordoes not have authority to access the files will be detected. In thoseinstances, where the preliminary screening still allows an unauthorizedadministrator to obtain a lock, the system is no worse off than it hadbeen previously.

Another advantage of embodiments of the present invention is that theadministrator who has locked a set of files will be identified to a newadministrator attempting to access those files. This identification caninclude an identification of the administrator holding the lock and, insome cases, contact information. Therefore, a qualified, pre-screenedand authorized new administrator can contact the prior administrator torequest that the lock be removed.

These and another advantages of the present invention will no doubt willbecome apparent to those of skill in the art upon reading of thefollowing descriptions and a study of the several figures of thedrawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of a database management system with locks inaccordance with embodiments of the present invention;

FIG. 2 a is a screen shot of a sample set of records accessible in thedatabase system of FIG. 1 as seen by a prior administrator;

FIG. 2 b is a screen shot of an attempt of a new administrator to accessthe same set of files as the prior administrator of FIG. 2 a.

FIG. 3 is a diagram of an exemplary Human Resource (HR) database model;

FIG. 4 is a flow diagram of an embodiment of a method for handlingdatabase locks in accordance with the present invention;

FIG. 5 is a flow diagram of the operation “IS THERE A CHANCE THAT THEREIS AUTHORIZATION?” of FIG. 4; and

FIG. 6 is a flow diagram of the “INFORM USER OF LOCK” operation of FIG.4.

MODE(S) FPR CARRYING OUT THE INVENTION

In FIG. 1, a database system 10 including locks includes a number ofadministrator terminals 12 coupled to a database server 14 whichadministers a database 16. Typically the database is stored in acomputer readable medium such as, for example, a hard disk drive,semiconductor memory, a tape drive, or an optical disk drive.

It should be noted that the database system 10 is illustrated in afunctional, rather than physical, form in that the functionality ofadministrative terminals 12, database server 14, and database 16 can beimplemented on one or more physical devices. Typically, however, each ofthe administrative terminals 12 comprises a personal computer orcomputer work station available for use by a human administrator.Likewise, the database server 14 can be implemented in one or morephysical servers or computer systems, typically dependent upon the scaleof the database system. For example, if the database system 10 isdesigned to support the HR function of a large, international company,the database server 14 may comprise dozens or even hundreds of separateservers located around the world. Likewise, the database 16 can belocalized or distributed.

The terminals 12, database 14, and computer readable media 16 can bedirectly coupled together, or can be linked together for communicationsvia, for example, a network, as be well appreciated by those skilled inthe art. Often, the network is a TCP/IP network in the form of one ormore of, for example, a local area network, an Intranet or the Internet.In the case of publicly accessible networks such as the Internet,security protocols (e.g. encryption) are typically used to prevent theunauthorized access to confidential information.

Administrators attempt to access files through database “queries”, as iswell known to those skilled in the art of database management. As notedpreviously, a problem can occur when a first administrator (“prioradministrator”) on a first administrator terminal 12 causes a “lock” ona file or set of files. This means a second administrator (“newadministrator”) and subsequent administrators cannot fully access thatset of files 18, or may not be able to access the files at all until thelock is removed.

As used herein, “set of files” shall mean data including at least onefile having at least one record. Therefore, a “set of files” can includea single file or even a single record, although typically it includes anumber of files, each of which includes a number of records.

In FIG. 2 a, a screen shot 20 illustrate a HR master data page for ahypothetical employee by the name of Miss Pia Vier. Miss Vier isassigned personnel number “31415” and has personnel records fallingunder a variety of “Infotypes” including personal data, addresses, bankdetails, etc. as shown on the left hand side of her basic personal datafolder. Other folders such as “contract data,” “gross/net payroll,⇄ “netpayroll,” etc. are shown hidden behind the basic personal data in thisview. On the right hand side of the screen shot 20, a number of searchparameter fields are provided such that the administrator can searchthrough the various records for this employee.

In FIG. 2 b, a screen shot 22 illustrates the screen that is seen on anew administrator's terminal for a new query. In this instance, it canbe seen that most of the identification information concerning employee31415 is not available. This is a first indication that a prioradministrator has a lock on this employee's files. Furthermore, in thescreen shot 22 an indication of the identity 24 of the prioradministrator indicates that “KLEINU” is the holder of the lock. Contactinformation 26 (in this case KLEINU's telephone extension “x1234”) canbe provided such that KLEINU can be contacted to determine whether thelock can be removed from these records.

In FIG. 3, a diagram of a particular example of a database structureconsistent with the aforementioned HR database is shown. It should benoted this database structure is presented by way of example only, andnot limitation. That is, there are many ways to create records, files,and sets of files with respect to database management systems, as wouldbe appreciated by those skilled in the art. In this diagram, a person(employee) is designated as CP, while various work assignments or“contracts” for the person are designated as P, where the set of P filesis designated as {P1, P2, . . . , PN}. This is in recognition of thefact that in large companies an employee CP may have several distinctjob functions P, each with their own parameters.

For example, in a multinational company, an employee may have a job as asoftware developer in his home country, and a software salesman inanother country. As another example, an employee may have a half-timejob as an administrative assistant during the morning hours, and ahalf-time job as a graphical designer in the afternoon hours. Therefore,in recognition of the fact that an employee can have multiple workassignments or “contracts” with the company or organization, ahierarchical file structure is set up with the CP files at a root leveland a P files branching from the root level. Each of the P files willinclude various “Infotype” records including, for example, address, pay,challenges, garnishments, etc.

It should be noted that a number of the Infotypes for a P file will bethe same regardless of the contract. For example, the address,challenges, garnishments, Infotypes will be the same for each of the Pfiles under a particular CP file because they refer to the same person.However, other Infotypes such as the organizational assignment, pay,etc. maybe different from P file to P file. Therefore, access authority(i.e. privileges) for each CP and P file, and each Infotype, may varyfrom administrator to administrator.

In the past, the problem sometimes occurred that an administratorattempting to access, for example, Infotype garnishments of a file P1creates locks on all of the P files and the CP file as well. This isbecause the system has to assume that the administrator accessingcontract P1 could change common Infotypes such as address, challenges,etc. and, therefore, the entire CP file should be locked. However, thiscreated inefficiencies in the past since the administrator making thequery might not even have the authority view the garnishments records,for example. That authority would be determined by a set of privilegesthat depends upon the rank, security clearance, seniority, conflicts,etc. of the particular administrator.

In particular, where there are hundreds of administrators, each of whichmay have many different preferences, it is very difficult to determineconclusively in advance whether an administrator has the authority toaccess a particular set of records. An aspect of the present inventionaddresses a new method for handling database locks which reduces thechance of an inadvertent lock on a set of records.

In FIG. 4, a process 28 illustrates an embodiment of a method forhandling database locks in accordance with the present invention. Theprocess 28 begins at 30 and, in an operation 32, is determined if thereis a new query. If not, operation 32 continues to loop in a wait loopuntil a new query is observed. Once a new query has been observed, anoperation 34 determines whether there is a chance that there isauthorization for the new administrator to access the requested set offiles. If not, an operation 36 informs the new administrator and returnsprocess control to operation 32 to await a new query. However, if thereis a chance that there is authorization, an operation 38 attempts toacquire a lock on the set files. An operation 40 then determines whetherthe attempt of operation 38 was successful. If not, an operation 42informs the new administrator that there is already a lock on the set offiles, and an operation control returns to operation 32.

If, on the other hand, the operation 40 determines that the attemptedlock acquisition was successful, the new administrator is provided withaccess to the set of records in an operation 44. Also, since the newadministrator has successfully acquired the lock, he or she becomes theprior administrator and the lock becomes a prior lock to any subsequentadministrator. The administrator continues to process the records in anoperation 44 until the administrator “checks-out” from the record, i.e.finishes with the record and releases the lock. An operation 48 thenunlocks the records and operational control returns to operation 32 toawait a new query.

In FIG. 5, the process 34 (“IS THERE A CHANCE THAT THERE ISAUTHORIZATION?”) is illustrated in greater detail. Process 34 begins at50 and, in an operation 52 it is determined whether the administratorhas write authorization. If not, it is determined that administrator hasno chance of obtaining a lock on the system in an operation 54 and theprocess 34 is complete at 56. If the administrator does have writeauthorization as determined by operation 52, an operation 58 determineswhether the administrator has the maximum authorization available forthe system. This can, for example, be provided to a master systemadministrator. If so, it is determined that there is at least chancethat this administrator has access in an operation 60 and the process iscomplete at 62.

Alternatively, if operation 58 determines that the administrator doesnot have the maximum authorization level, an operation 64 determineswhether the employee number matches the administrator. Typically, anadministrator is not permitted to change certain of his or her ownemployment records due to potential conflict of interest. If theemployee number does match the administrator, it is then determined anoperation 66 if the access is minimal, e.g. to non-critical informationsuch as the administrators' home address. If not, e.g. the administratoris attempting to accessing his or her own pay records, a conflict ofinterest is detected and process control is returned to operation 54.

If, however, the operation 66 determines that the access to the set ofrecords is minimal in nature, an operation 68 determines whether theadministrator is authorized to have access to sets of files relating topersonnel in that particular part of the organization. If not,operational control is turned over to operation 54 indicating there isno chance of authorization. However, if the administrator is currentlyauthorized, as determined in an operation 70, operational control isturned over to operation 60 indicating that there is a chance ofauthorization and, if not, process control is turned over to operation54 to indicate that there is no chance. In either case, the process 34would then be complete.

In FIG. 6, the operation 42 (“INFORM USER OF LOCK”) of FIG. 4 isillustrated in greater detail. Process 42 begins at 72 and, in anoperation 74, it is determined who is the holder of the lock, i.e. whois the prior administrator. In an operation 76, contact information canbe looked up for the prior lock holder. In an operation 78, therequested can be informed in the lock with contact information of theprior lock holder. The process 42 is then complete at 80.

Referring again to FIG. 2 b, it can be seem that informing the newadministrator that there is a lock can take several levels. On thesimplest level, a new administrator can simply be informed that therecords are locked without any indication of who holds that lock. Onanother level, the holder of the lock can be identified e.g. in thiscase KLEINU. On a still further level contact information can beprovided, such as the extension number x1234 of the prior administratorKLEINU. Of course, as will be apparent to those skilled in the art,there are other forms of contact information that can be provided to thenew administrator, such as the e-mail address, pager number, cell phonenumber, etc. of the holder of the prior lock.

A primary example in the preceding descriptions has been in the contextof a Human Resource database management system. As is no doubt apparentto those of ordinary skill in the art, aspects of the present inventionare useful a wide variety of database applications employing locks. Itis therefore intended that the preceding examples be considered by wayof illustration, and not restriction, and that present invention beinterpreted as including all those modifications, permutations,extensions, equivalents, and the like that fall within the true spiritand scope of the present inventions.

1. A method for handling database locks comprising: detecting a newquery from a new administrator for a set of database records that areassociated with a potential new lock; determining whether said newadministrator has any chance of being authorized to acquire said newlock; attempting to acquire said new lock if said new administrator hasa chance of being authorized; and informing said new administrator of afailure to acquire said new lock if a prior lock has already beenacquired due to a prior query by a prior administrator.
 2. A method forhandling database locks as recited in claim 1 wherein informing said newadministrator includes identifying the prior administrator.
 3. A methodfor handling database locks as recited in claim 2 wherein informing saidnew administrator includes providing contact information for said prioradministrator.
 4. A method for handling database locks as recited inclaim 1 further comprising informing said new administrator that saidnew administrator is not authorized to acquire said new lock if it isdetermined that said new administrator has no chance of acquiring saidnew lock.
 5. A method for handling database locks as recited in claim 1further comprising permitting access to said set of database records ifsaid new administrator acquires said new lock, and designating said newadministrator as a prior administrator and said new lock as a priorlock.
 6. A method for handling database locks as recited in claim 5further comprising releasing said prior lock after said prioradministrator has checked out from said set of database records.
 7. Amethod for handling database locks as recited in claim 1 whereindetermining whether said new administrator has any chance of beingauthorized to acquire said new lock includes whether said newadministrator has write authorization for said set of database records.8. A method for handling database locks as recited in claim 1 whereindetermining whether said new administrator has any chance of beingauthorized to acquire said new lock includes whether said newadministrator has a maximum database access authorization.
 9. A methodfor handling database locks as recited in claim 1 wherein determiningwhether said new administrator has any chance of being authorized toacquire said new lock includes whether said set of database recordspersonally pertain to said new administrator.
 10. A method for handlingdatabase locks as recited in claim 1 wherein determining whether saidnew administrator has any chance of being authorized to acquire said newlock includes whether said new administrator is organizationallyauthorized.
 11. A method for handling database locks as recited in claim1 wherein determining whether said new administrator has any chance ofbeing authorized to acquire said new lock includes whether said newadministrator is currently authorized.
 12. A computer readable mediaincluding program code segments for handling database locks comprising:a code segment detecting a new query from a new administrator for a setof database records that is associated with a potential new lock; a codesegment determining whether said new administrator has any chance ofbeing authorized to acquire said new lock; a code segment attempting toacquire said new lock if said new administrator has a chance of beingauthorized; and a code segment informing said new administrator of afailure to acquire said new lock if a prior lock has already beenacquired due to a prior query by a prior administrator.
 13. A computerreadable media including program code segments for handling databaselocks as recited in claim 12 wherein informing said new administratorincludes identifying the prior administrator.
 14. A computer readablemedia including program code segments for handling database locks asrecited in claim 13 wherein informing said new administrator includesproviding contact information for said prior administrator.
 15. Acomputer readable media including program code segments for handlingdatabase locks as recited in claim 12 further comprising a code segmentinforming said new administrator that said new administrator is notauthorized to acquire said new lock if it is determined that said newadministrator has no chance of acquiring said new lock.
 16. A computerreadable media including program code segments for handling databaselocks as recited in claim 12 further comprising a code segmentpermitting access to said set of database records if said newadministrator acquires said new lock, and designating said newadministrator as a prior administrator and said new lock as a priorlock.
 17. A computer readable media including program code segments forhandling database locks as recited in claim 16 further comprising a codesegment releasing said prior lock after said prior administrator haschecked out from said set of database records.
 18. A computer readablemedia including program code segments for handling database locks asrecited in claim 12 wherein determining whether said new administratorhas any chance of being authorized to acquire said new lock includeswhether said new administrator has write authorization for said set ofdatabase records.
 19. A computer readable media including program codesegments for handling database locks as recited in claim 12 whereindetermining whether said new administrator has any chance of beingauthorized to acquire said new lock includes whether said newadministrator has a maximum database access authorization.
 20. Acomputer readable media including program code segments for handlingdatabase locks as recited in claim 12 wherein determining whether saidnew administrator has any chance of being authorized to acquire said newlock includes whether said set of database records personally pertain tosaid new administrator.
 21. A computer readable media including programcode segments for handling database locks as recited in claim 12 whereindetermining whether said new administrator has any chance of beingauthorized to acquire said new lock includes whether said newadministrator is organizationally authorized.
 22. A computer readablemedia including program code segments for handling database locks asrecited in claim 12 wherein determining whether said new administratorhas any chance of being authorized to acquire said new lock includeswhether said new administrator is currently authorized.
 23. A method formaking a preliminary determination as to whether a databaseadministrator has authorization to access a set of database recordscomprising: determining that a database administrator has no chance ofbeing authorized to access a designated set of database records if saiddatabase administrator does not have one or more of: (a) writeauthorization for said designated set of database records; (b) if saiddesignated set of database records are personal database records of saiddatabase administrator of a type likely to create a conflict ofinterest, (c) if the database administrator is not organizationallypermitted to access said set of database records; or (d) if saiddatabase administrator is not currently authorized; and determining thata database administrator has a chance of being authorized if saiddatabase administrator has one or more of: (a) write authorization andmaximum administrator authorization; and (b) write authorization, notmaximum authorization, not if said designated set of database recordsare personal database records of said database administrator of a typelikely to create a conflict of interest, if the database administratoris not organizationally permitted to access said set of databaserecords, and currently authorized.
 24. A computer readable mediaincluding program code segments for making a preliminary determinationas to whether a database administrator has authorization to access a setof database records comprising: a code segment determining that adatabase administrator has no chance of being authorized to access adesignated set of database records if said database administrator doesnot have one or more of: (a) write authorization for said designated setof database records; (b) if said designated set of database records arepersonal database records of said database administrator of a typelikely to create a conflict of interest, (c) if the databaseadministrator is not organizationally permitted to access said set ofdatabase records; or (d) if said database administrator is not currentlyauthorized; and a code segment determining that a database administratorhas a chance of being authorized if said database administrator has oneor more of: (a) write authorization and maximum administratorauthorization; and (b) write authorization, not maximum authorization,not if said designated set of database records are personal databaserecords of said database administrator of a type likely to create aconflict of interest, if the database administrator is notorganizationally permitted to access said set of database records, andcurrently authorized.
 25. A database system including locks comprising:means for detecting a new query from a new administrator for a set ofdatabase records capable that is associated with a new lock; means fordetermining whether said new administrator has any chance of beingauthorized to acquire said new lock; means for attempting to acquiresaid new lock if said new administrator has a chance of beingauthorized; and means for informing said new administrator of a failureto acquire said new lock if a prior lock has already been acquired dueto a prior query by a prior administrator.
 26. A database systemincluding locks as recited in claim 25 wherein informing said newadministrator includes means for identifying the prior administrator.27. A database system including locks as recited in claim 25 whereininforming said new administrator includes means for providing contactinformation for said prior administrator.
 28. A database systemincluding locks as recited in claim 25 further comprising means forinforming said new administrator that said new administrator is notauthorized to acquire said new lock if it is determined that said newadministrator has no chance of acquiring said new lock.
 29. A databasesystem including locks as recited in claim 25 further comprising meansfor permitting access to said set of database records if said newadministrator acquires said new lock, and means for designating said newadministrator as a prior administrator and said new lock as a priorlock.
 30. A database system comprising: a plurality of administratorterminals; a database server capable of being accessed by a plurality ofadministrators associated with said plurality of administratorterminals, said database server including, at least in part, a databaseprogram capable of managing a plurality of records that may be groupedinto sets of records, said database program including the functionalityof: (a) detecting a new query from a new administrator at a newadministrator terminal for a set of database records capable that isassociated with a new lock; (b) determining whether said newadministrator has any chance of being authorized to acquire said newlock; (c) attempting to acquire said new lock if said new administratorhas a chance of being authorized; and (d) informing said newadministrator at said new administrator terminal of a failure to acquiresaid new lock if a prior lock has already been acquired due to a priorquery by a prior administrator on a prior administrator station.
 31. Adatabase system as recited in claim 30 wherein informing said newadministrator includes identifying, on said new administrator station,the prior administrator.
 32. A database system as recited in claim 31wherein informing said new administrator includes, on said newadministrator station, providing contact information for said prioradministrator.
 33. A database system as recited in claim 30 furthercomprising informing said new administrator on said new administratorstation that said new administrator is not authorized to acquire saidnew lock if it is determined that said new administrator has no chanceof acquiring said new lock.
 34. A database system as recited in claim 30further comprising permitting access to said set of database records viasaid new administrator terminal if said new administrator acquires saidnew lock, and designating said new administrator as a prioradministrator and said new lock as a prior lock.